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As tmma netwQilcs become larger (often involvinE Omasaaia of demeiitt). 
moK he^n«eneoiis (sappoftiBg . «rie^ of derlces ana pnXocob), and iiitte 
A. tn^J^^'^ Cuml^ subtle interactions and relationsIii|» unong componra^ 
«r^^r£?^I!f w°"**2r* "?n«««nent for laise^e systems incKH^ For tte 
woric 10 be the Infonnalion h^way for an enteipiise, then most exbt efitetln maun- 
meat tools to easne smooth and cflideiit aperattons. 

«A SSSfS*''^^'*.* "IST^ ^ managed today by a set of Bonintagrated tools. 

i^S? soompllsWng effeetire ma^^rt(see 
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■*« ^^«*"Poncnt Of a network management environment is 
lSf??!^5*^fil^^™^H:™s "^odel presents to management 
tools the knowleci^e available to the management system. The 
oijgmzation of such a modd and its architectural relationship 
wth the nmnagcmcat tools are the central theme of this article. 
The problem of effective network modeling gives rise to diffi- 
ailt technical challenges. The netwoik objects whose opera- 
tionai beteinor must be captured by the model are typicaUy 
distributed. For example, a virtual ciicuit in an X.23 network 
may myolvc a set of distributed processes and data structures 
rawntamedbymultipleswitchesandnrt^^ 
state of such a distnbuted object may be only partiaUv ob- 
served by eadi individual device that support/if. Reports^ 
sue* observauons to a central modeling fedUty may be incon- 
ttrtent. eg., one switch believes the circuit is lost while another 
^ST^-"**? operating. A modeling fecility may thus have to 
handle mtrmsicaUy mconsistent data. How can concerted 
^^^«a«ion^>cacfticvcdinthcpresenceofsuchin^ 

I h ^ V^^o'? objects in the networic may be ' 

I tatfUy In a muhilayered protocol, the bdiavior of 

an entity m one layo: may be Implemented in terms of a set of 

^SJS^^' ^ ^« Transmission 

Orattol Roioa)yimeniet Protocol (TCP/IP) suite, a Tehict 
wtoaltra depends on the weU-being of 

net wrWaycr (IP) flmcUons. A faU- 

n filM^ connections may lead to correlated 
failurw in the higher layers. This nuwing of hiycred objects 

^doSf Sfil^?!2°^^ "^ot aU behavior wnc 

i^'': oapt""^ by static configurational relations. 
^oLS'^^'" dynamic interactions 

Si??**?^ ^^l example, the noise levels associated with a 
^ cpirclatcd with the rate of control packets 
^ It IS necessary forthe model to represent 

such dynamic rehitiotts as weU as more static relations. How 

^^fffS?A by Defenw Advanced Resewch Projects Agcn- 

2^^?^''S^r?S?<^^^^ NY Slatc'cAT^. 

S^tlKdiSi^*^^- herrfn are strictly 
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can a model represent a spectrum of correlations among object 
behaviors? 

Another problem is that of many different protocols nm- 
ning on a single network, with intricate dependencies between 
^bother. For example, it is common for an enterprise to have 
both Ethernet and token ring with protocols such as TCP/IP 
and DECNet over Ethernet and TCP/IP and Systems Network 
Architecture (SNA) oyer toten ring operating concurrently. 
Existing protocol-specific network management systems typi- 
cally have models that reflect only the properties and relation- 
ships suppmed within their protocols, and cannot support the 
analysis of in terdependency information. 

The NETMATE project is building a collection of tools for 
comprehensive networic management in a distributed environ- 
™JJt, addressing management problems such as those de- 
acnbed above. The overall design emphasizes a distributed ap- 
proodu the definition and ooUeciion of networic infonnation 
and the storage, analysis, and review of this information, may 
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Bg. 2, Vt component 
occur at several locartons. The ceniral xSxznie, of NETMATE is 
the design and implementation of a generic data model to rep- 
resent network entities and their interrelationships. The model 
is extensible as it pemits the addition of newprotocols and en- 
tities with different sets of properties and onolyds procedures. 
Hiese tools, developed arotmd tUs geneiic netteik model 
conoqrt, address a varied set problems in day-to-day net- 
woric management. 

Th e rest of the article is orsanized as follows. The overall 
l^ETMATEaidittecture bdiscussed next The problem of net- 
work niodelmg and theNEIMATEapproadi to itare^ 
seated. The current implementation status of NETMATC is 
^ven, and conclusions are in the final section. 

Overall N£TMATE Architecture 

The NETMATE architecture is a collection of network 
xmmagemcnt tools. The mf^or components of a complete 
NETMAIB environment are the Modeler, UserIaterface(UI). 
Observation/Control Point (OCPX Simulator, and auxiliary 
systems (see Figure 1). In the Mowing, we describe the netr 
work manaeement flnictions perfonned by each component. 

Modder 

The NETMATE Modeler component supports the repre- 
sentation of complex network modds in order to permit effi- 



cient interpretation and response to problems. Additionally, it 
allows other NETMATE components to commimicate with 
eadi other by serving as the hub of the system. As the primary 
repository ^ information, it connects the other components 
together. All other components function as diento of the 
Modeler. In a distributed implementation, the Modeler also 
provides services to other NETMATE environments in the 
system and takes part in the coordination of information flow 
with other Modelers. The Modder is implemented usmg a da- 
tabase, so that it is easy to provide database &dlxties like 
concorrency control and recovery to the clients. The "Network 
Modd** section will descriln:, in detail, the NETMATE ap* 
proadi to network information modding as implemented by 
the Modder. 

User Interface 

The UI component provides the ability to visually navigate 
and control complex network scenarios. The UI maps numer- 
ous objects and relationships into a visual representaticui for a 
human network manager. Furthermore, due to limitations of 
visual displays, the UI supports multiple visual abstractians to 
reduce dutter and focus on the entities of interest 

A simple but important feature is that a user may see multi- 
ple views of the network simultaneoudy. The UI allows the 
network to be viewed at multiple layers, eg., the IP network 
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layerorSNAIinklayer.ConsideranetwoikconsistingofLocal 
Area Networks (LANs) (Ethernet end token ring) with multiple 
hi£$i6r4ayer protocols (TCP/IP and SNA) (see Figun 2). Dur- 
inga problem-determination scenario in tiie SNA network, the 
user may begin with the SNA view,< which is depicted in the 
bottom4eft window in the figure. Assume that a problem is de- 
teimined in an SNA link between the nodes NCP18 and AS/ 
400, which maps to a token ring. The token ring network view 
may then be made visible, as is depicted in the top-rig^t win- 
dow. The views not of interest may be ioomzed (bottom right). 

An additional technique used to redueedutteris the hierar- 
chical display concept in the Ui. As the token ring network 
view is shown to the user, all visual groups within tfaiP view that 
are not of interest (ut^ the entities that m not part iof the SNA 
link having the problem) may be display in an Iconized Ibnn 
^ (e^, the three smaller squares at the top of the token ring 
view). The decision of which groups to make visible depends 
on the policy employed in the UI to map network'model infor- 
mation to the visual model information. By using the facilities 
of the control panel and the menu ch<wcec» the user may deotdo 

to take fbrther actions to resolve Ae problem. 
Obsmadon and Control Point 

In NETKCATE, access to the o^ccta in the network is pro* 
vided by OCPs. An OCP is a management agent, and it uses 
mam^-agent protocols to support communication. An OCP 
functions as a filter to reduce the amount of information and 
updates being sent to the Modder, as well as perform tRmsIa- 
tion functions between the native management protocols used 
by devices and the Modeler interfece. A generic 0(n> of the 
type described in (2] can handle dynamic filtering and transla- 
tion criteria as required by managers, using software and pro- 
tocol stmctures that permit managers to ddegate management 
programs to agents. 

The separation of OCF modules and funcdons from the 
Modeler is significant in two ways. Hrst, by keeping the inter- 
Uax between the NETMATE system and Other network man- 
agement systems in a separate component, it is possible to 
avoid having many dififerent device-dependent and protocol- 
spedfic routines in the Modeler. Second, it allows a convenient 
addition of inter&ocs from the Modeler to new networks. The 
only protocol the Modeler has to follow is the manager-agent 
protocol 

An unportant feature of the manager-agent protocol allows 
the Modeler to inistnict an OCP to send information to the 
Modeler when a specific event occurs. This instrucdon is con- 
veyed by delegating a management program to the OCP, fox 
example, the program may return status mformarion of a basi- 
cally static network entity only when its value changes; or when 
it changes beyond some threshold. Another example of a man- 
agement program is one that converts polling of devices into 
alerts and vice versa. If a networic device is not intelligent 
enough to generate alerts when problems exist, a management 
program can poU ihat device and send an alert to the Modeler 
indien h detects a problem. On the other hand, a device may 
generate many alerts that are of no interest unless there is some 
other problem indication. In this case, a management program 
could just store the alerts, end would be poUcd by the Modder 
whenever other problems were detected. 

Sinmlalor 

NETMATE eichitecturo includes a simulation component 
for building •what-ir analysis capabilities into a n^woric 



'Since NETMATE does not dictate a layer to be defined based on 
any otisting network protocol layer, it b possible, for example, to 
moddall SNA entities to be hiasingiehiyer, and henceasingle view. 



management system. It addresses the problem of incoiporating 
simulated scenarios with management c^abilities as a means 
to examine and debug planned nctwoik enhancements, and 
also for operator training. This feature is also useful in network 
design and research in network protocols and distributed sys- 
tems [3). 

A typical use of the simulation capability under o **what-if 
scenario is illustrated by this example: Take a snapshot of the 
current network state from the Modeler, load it into the Simu- 
lator, alter the network configuration, and observe the efliects 
in the simulated networic Temporal information stored in the 
Modeler could be particululy useful for devdoping models of 
the vuiotis netwoA components for the simul^on. This sce- 
nario is just one case of a more general use for simulation as a 
bridge between netwoik management on the one hand, and 
network design and cecity planning on the other. ~ 

From a networic simulation perspective, integration with a 
network management system is also usdiiL bi a typical scenar- 
io for network protocol reseucfa, the features of and analy- 
sis toob developed for network management aic exactly What 
is needed for getting information sudi as padcet counts and 
rates, traffic tevds, and loads out of a network simulation and 
presentingittoaresearcherin an easily imderstood manner. 

Auxiiiary Systems 

Auxiliary systems can use the network database services of 
the Modeler to support other related activities, sudi as inven- 
toty and trouble ticketing. As other system management csqm* 
bilities become available, sudi as managing user acc ounts, 
storage devices, and file systems, we will use the NETMATE 
moddto manage these as welL 

NETMATE maintains information useful to other systems. 
For example, the configuration database can be used for inven- 
tory control, tracking specific hardware and software systems 
m the networic If vendor and price information is added, such 
a comprehensive system may be used by the purchasing de- 
partment With such information, when a prd)lem is recog- 
nized with some equipment, quick servicing or reordering ac- 
tions can be carri^ out 

NETMATE indudes a Trouble Ticketing system. This sys- 
tem is used for recording network problems and their handling. 
Typically, a ticket is created for every reporUd trouble, and its 
status changes as it undergoes investigation and is eventually 
resolved. The Modeler maintains information about long- 
lasting network problems. The Trouble Ticketing system is 
also used as a reference facility. When a problem is reported, 
old trouble tickets are queried to suggest a course of action. It is 
designed to identify problems tiiat are more fiequent and 
hence need special attention. 

Network Model 

In discussing the network model of NETMATE, we will use 
a network example lo examine a number of network manage- 
ment scenarios and how the model would support manage- 
ment operations. Cbnsider a link-layer network of an Ethernet 
(£) with two nodes (A and B) and a token ring (7) with one 
node (D) (see Figaro 3). E and Tave connected by a bridge (Q. 
The Ethernet E is divided into two segments joined by a re- 
peater (R). Additionally, C is also connected to a serial line (5). 
Using this simple network as an example^ we will daborate a 
few nontrivial problems asfiodated with networic modeling, 
and present NETMATE solutions with qualitative compari- 
sons of the NETMATE modd with other standard modds. 

Consider a network pvtsblem where B is unable to commu- 
nicate withD. An analysis process may attempt to construa all 
possible connection pMhs from B to D, and test components in 
each path to determine the problem. The program may disoov- 
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Fig. i. N&WKkexample. 



er that these nodes are on different types of links, and then at- 
tempt to find a bridge (amone all bridges in the network) that 
may have both nodes in its forwarding table property.^ Using 
on^ the information from the nodes (assuming they are 
ieacfad>Ie from the management system), it will have to algo- 
rithmically deduce which Ethernet and tokai ring segmeiits are 
pan of the connection between B and D to construct the con- 
nection paths. This process becomes more complex if the 
nodes are separated 1^ more than one bridge. Aho note that 
the analysis program has to understand individual nodes* ven- 
dor- and protOGol-9pecific properties to conatnict the paths. 

The process is simplified if the model allows lepresentation 
of generic object dasses, node and link, and a generic connec- 
tion relationship between instances of these dasses. The rela- 
tion in the model is maintained as nodes get connected to the 
links in the network. Thus, the connection relation at the be- 
ginning of the analysis has the infonnation that E is connected 
to A, B, and C and rto C and D. Given such a model, it is feir- 
ly easy to use a naph-topologicai algorithm to construct the 
connection path 6-£Or«D before testingany individual com- 
ponent in the network. Furthermore, since it is also known that 
A is connected to A maybe directly queried to check the sta- 
tus off, which is not possible in the bitemational Organiza- 
tion for StamSanUzailon (ISO) model unless it has been previ- 
ously deduced that A and B are on the same link Also note 
that with this information, the iKOh-searching algorithm need 
only lotik at the connection relation and not at any protocol- 
Gpeoifio propertxe8 of the aodea. The same infonnation may be 
used to easily create a display of the networl^ as shown in Fig- 
ure 3. 

Hie NETMATE modd, based on object-oriented database 
technology, Indudes the generic node and link <^:uect dasses 
and the connection relation (see Figure 4) in its dass hierarchy. 
Note that links in the network are not active components; the 
model, nevertiidess, distinguishes different properties be- 
tween nodes a nd lin ks, and makes it explicit through dass defir 
nitions. The NETMATE UI module makes use of the connec- 
tion relation in displayhig network objects. 

Assume that in tiie network example, the Ethernet segment 
that connects to B , physically has a repeater R due to distance 
limitations. The analysis process, upon querying A, determines 
that there exists a path from A to D. I^e problem, thus, is in 
the Ethernet segment that connects B, or that segment's physi- 
cal cable connection to B, or at B itseUl To investigate forther, 
the pioem needs to fallow the ooRospottdSng pi^aical-laycr iii- 
foiniation,Le.» that the Ethernet in thelinklayerts implement- 
ed intenns of phyrical-layernetwoifcdbjectssttdi as repeaters, 
s^ments, and hid)s. Note that this investigatio n of the physical 



^TUs infomia!ion may not be found if the bridge uses an adaptive 
algoiithm, and the entries are ddeted due to tuneouL 
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layer is unnecessary until the time the £uilt is determined to be « 
in a specific Jink layer object 

In general, in almost all protocols there is a layering concept 
in which a network component at one layer is ixnplemented in 
tenns of a set of network components at another layer. This ^ 
basic concept is represented in NETMATE using the layer ob- 
ject dass and the mapping relation. Given this generic infor- 
mation, the analysis process may continue investigation of ob- 
jects that a problem object maps to at another layer. Once 
again, although the mapping between objects is dctciinincd by 
the spedfic nature of individual protocols, the analysis process 
is generic in t hat it needs to know only the mapping rdation. 
Note that in NETMATE, a layer is indq}endent of a spedfic 

protppoi suite, and there 1$ no piecbnceived notion of a ''high- 

er"* or **lowei^ layer. This is useful in scenarios where in some 
part of the network DECNet runs ovarEP and, in another part, 
IP over DECS^et 

Consider an example where the communication problem 
occurs at C due to unavailability of memory buffers for the 
bridging of E and T. Having detected the problem at Q the 
analysis process needs to examine the traffic bdiavior on xdl i n- 
dividual interiaoes in C, induding the one to since sum-total 
use of buflfers at C depoads on all three inter&ces. The generic 
modding need, therefore, is to be able to represent subobjects 
of an object by the rdation components. This allows Cto have 
three subnode components, each mth an independent set of 
properties contributing to the sum-total properties of C. Addi- 
tionally, the NETMATE semantics to this rdation are that 
while a subnode has all the same properties as a generic node, it 
cannot exist independent of its supemode. The component 
concept is also useful for link objects, such as for modeling of 
SNA Multidrop lines, and SNA Twinax connections. 

Consider an example where the token ring has many nodes 
that communicate with B (perhaps an application server), and 
C is inoperative. When invoked as a result of IMo-B communi- 
cation failure, if the analysis process determines the cause, it 
need not perform the analysis again for any other similar token 
ring node. This correlation may be achieved by grouping such a 
set of network objects under a conmiou criterioiL In general, 
sudi grouping needs arise due to many reasons, such as organi- 
zational hierarehy, topolo^cal or geographical proximity, and 
reporting and analysis processes. This is rq>resented in 
NETMATE by the group object dass and the grouping rda- 
tionship. Groups are also used by the XJI module to create vbi^ 
al groups on the display. 

Consider an example of a problem that is specific to a ven- 
dor implementation of Ethernet connections for A and B. In a 
heterogeneous environment, it is not possible for an analysis 
process to always come up with a solution and corrective ac- 
tions based only upon generic information. The model must 
therefore accommodate spedfic information and testing and 
corrective processes, whicii may be invoked by analysis proce- 
dures once t he m anagement context is determinel This is 
achieved in NETMATE by user^efined types, methods, and 
inst ances that inherit the generic properties and rdationkups 
of NETMATE object dasses. These defiiutions are supported 
in NETMATE as additional network-specfflc-type hlenuchies 
under the basic object classes (eg., the TCP virtual circuit class 
in Figure 4). 

I The existing two standard data modda, known as Structure 
of Management Xafonaation <SMX), aro the Internet SMI [4] 
and the ISO SMI[5]. These Standards provideaconuHonstruo> 
ture for management data for heterogeneous networics, and 
allow a medianism for the ddEhtition and naming of variables 
containing management information (essentially, name-value 
pairs). Some additional structuring is provided; tables of varia- 
bles can be defined (although the Intmet SMI does not sup- 
port nested tables). The ISO SMI has an ofatject-oriented modd, 
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Fig. 4, Network model doss hierarchy. 



mecbanism for definme oljcet daaws, and « single contain- 
ment relationship betwew oWemT^ wawin 

Class, eacli node is represented as an instance of a protocol- 

stance tljat lias properties related to its Ethernet inteifkoe. 

lSF^?^fc«"^ Since the hnks are not directly n^resent- 

S ^"^ '^'^ «^ " Ethernet, and that two 

ntfamcaUy deduced, at a great cost, from the properties of k- 
f J^^J^ every time this network needs to be di^tey^ 

^t^l^^l^^ of network queries (model accesses) 
SLJSj?*tm?" J? fi«<««««a>tal relaUons mentioned 
J5?^!:^°^"*''H^^»oi^*5»suffidently rich set 
of these fundamental idationa. applicatioo, win incii 

^Kf?* ^°^-*? relationships (spedfi- 

M^lymawyng). whiAareesaentfalforeffidottautomatcdnet- 
work problem analysis. 

counted information to recommeiid specific actions; in other 
words, It must not only define and concct. but also mLiageti^ 
nfonnatton. The model, therefore, must allow foV^^iZ 
uon of nciworic management rules that aie appUcable on spe- 
afic ndwork objects. Based on infonnation in the notw^!^ 
modd, these rules are triggered for further analysis. Forcxam- 

• sunpie rule for the Modem class (where Jlf is an object in- 
stance for, say, a modem on 5). Complex analysis of network 



objects may be perfonncd as procedures with decision systems 
such as neural network and queuing analysis. These are neces- 
sary when simple deterministic steps are not sufficient For ex- 
ample, an extensive queuing and pattern analysis correlation 
may show that certain paiameteis such as Modsn.SoMd and 
nodea.paeket$iM need to be (^amically leasdgned over time 
to improve throughput 

Infoimation about previous values of management data, 
and expkdtly time-related information such as traces and data 
mes, need to be provided for. A trend analysis for modem 
throvghpm, for example, requires availability of data such as 
MOcfciB-Spee^ ltodni.PBek«tsizs, and nodem.NumPackets at frequent 
intervals of Ume. Furthermore the network being a real-time 
system, careful distinctions need to bo made bctwcca Cho real 
time Vfbea such values are sampled and the thne ^idien sudi 
values are stored in the model 

Further research issues and detailed descrq>tions for both 

Distribated Management Issnes 

This secdon examines the researdi problems m distributed 
network management Hrst, since network information is dis- 
tr^uied over network components, the management function 
p inherently distributed Second, this infoimation is collected 
in ^ model for management purposes, but the management 
architecture consists of distributed components, and thus the 
management protocol adds another layer, %^iich may be called 
distributed network management. 

^ The priuflfy fmoblem with distributed actirork infbima- 
bon IS that of the reliability or^irectoess of that information. 
For example, for passive network components such as links, it 
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is quite possible that a node connected to the link detennines 
thelinktobe operating, and another node, unable to connect to 
theli&k,determiaesittobeinopeiathpe.Wlulethetnfonxuti^^ 
seems to be inconsistent, both reports are true from the partial 
viewpoint of the observing nodes. 

If the netwoik model is considered inmply a database with 
serialianbility as the notion of correctness, the data in the 
model may not accuratdy reflect the networic being modeled. 
For eaomple, if the status of the link is updated simply by the 
last report from any node on the link, it is <iuite possible to have 
information in the model oontnuy to the real network, 
seiializability notwithstanding. The reason is that while tradi- 
tional database concepts impose the tradition that a transac- 
tion (typically written by humans) is assumed to be consistent, 
such an assumption Is invalid In a netwoik information data- 
base, when a tranaaction is an update of infonnation baaed on 
values retrieved fiom the network. Short of freezing all net- 
work activities, the bfoimation in the modd win ahvaysbeout 
of date with the ml netwoik information. Under such condi- 
tions, the consistency and timeliness of the network model 
may perhaps be attributed with only a "degree of confidence," 
Policies — sudi as '^a link is inoperative only if nugority of 
nodes report it to be inoperative for a duration of 10 s* — are 
examples of heuristic reasoning that may be applicable. 

Another issue in distributed management relates to possible 
network degradation caused by the management system itsel£ 
Considera very laige network with a single manager, excessive 
network management trafiic would adversely afiect both the 
networtc's and numage^s performance. In NETMATE, this 
problem is addressed by defining a management architecture 
consisting of elements in three levels: first, tiie network devices 
themselves; second, simple managmg agents (OCPs), which 
support the native device management protocol and the proto- 
col used by the distributed management system; and third, the 
managers themselves (see Hgure 5). As mentioned previously, 
the ideal management protocol supported by these manage- 
ment entitin is an active researeh topie p]. The architectuxe, 
however, ndses three other issues*— access, concurrency, and 
replication control — eadi with a apedal problem in tluB net- 
work management context 

Access control problems relate to deciding which managing 
entities have rights to control which OCPs and devices. Ulti- 
mately, if access control is not stjypported by the network devic- 
es, providirig it at the other levels is pointless. However, the 
type of access control supported by networic devices can be 
very primitive TaU-or-nothing"), and therefore, access control 
has to be built within the management structure of managers 
and OCPs. 

Concurrency control, on the other hand, may not be desir- 
able to implement in network devioea, since doing ao might 
prevent the ability to bypass the distributed management sys- 
tem ytben h is necessary to oonect a problem quickly. Addi- 



tionally, the complexity of supporting transactions in network 
devices is impractical. However, at the manager level where if 
will be quite conmion to have fidl database management sys- 
tems, concurrency control and transaction management sup- 
port will often be available at little incremental cost. Neverthe<^ 
less, in some cases, allowing concurrent management access to 
the network may not be desirable, as there are usually no ways 
to bade out from some actions such as 'Moot" 

When determining whether management infonnation 
should be replicated in more than one layer (or across 
Modclcn}, a tradeoif is made between providiiiig the most cur- 
rent and accurate infonnation and reducing the trafiic and 
load on network elements fiom frequent requests for the infor- 
mation. Additionally, replicated information may act as a 
cache to speed management applications. Other issues include 
how redundancy should be provided and how to configure the 
distributed system (cg^ network devices may not have sufiQ- 
dent mtdligence to choose primary OCPs/manageia» let alone 
backup OCPs/managcTs). 

While the OSI and Internet architectures address ^ese is- 
sues in part (mostly regarding access control medianisms), 
they do not address concurrency control, and other issues are 
dealt with incompletely. 

Since networks are thoroughly interconnected, a h^level 
application may communicate with another apidication at a 
distant node and cut across many management domain bounds 
aries. In such cases, spiH-over problems can occur in many 
ways: a problem in one domain may prohibit r^ular functions 
in other domains (for example, file transfer to a remote node 
lails at a regional network because the long distance network is 
down), or a problem in one domain causes active disorder in 
another df>n»g«" (for example, TCP/IP networics maybe flood- . 
ed with unnecessary address resolution protocol traffic due to 
improper configurations). A cooperative management strategy 
needs to be developed for distributed problems that q)an over 
management domains on inte rconn ected networks. 

The approach taken in the NETMATE system is to provide 
policies for struauring distributed management systems. For 
example, by limiting OCPs to communicate only with a single 
manager, access and concurrency control problems at that 
layer are subsianilaUy simpUfled. Also, having tHe OCFs hiiti- 
ate the connection to their manager, rather than vice versa, 
neaiiy eliminates the need for access control entirely. On the 
other hand, replicating data in the OCT can improve petfonn- 
onoe mgnifleantly without sacrifidagmudi aocuraqr in the in- 
formation. These issues form future researdi topics in 
NETMATE. 



NETMATE Status 

Currently, a prototype NETMATE system has been devel- 
oped at Columbia with a funotional Moddcr, UI, and OCP. 
The Modeler is implemented using the Vbase object-oriented 
database running on Suii-3 ™rf*itn^ the UI Is written in C -H- 
using the Interviews X window system toolkit from Stanford. 
G^e OCP has been developed, with a generic inter£ice using 
the Simple Networic Management Protocol (SNMP) to com- 
municate with managed network objects. Both the UI and 
OCP are currently nmning on Sun*4 machines. 

The development of the UI is ongoing, and enhancements 
and additional features are planned. A new OCP, written in 
C++ , which will provide more of the data transformation and 
reduction capabilities mentioned above, is under develop- 
ment A Modeler with cAject-oriented structures based on a 
rdailoual database Is planned, and Implementation should 
begin soon. A trouble-ticketing application wHI be written as 
this new Modeler becomes usable. The Nest netwofk^unula- 
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txoa tool devdoped at Gohimbia (3] wiU be used as the basb of 
a Simulator oomponent 

The existing and planned components of the NETMATE 
system are being used as a platform for research by project 
membeis in a number of areas: concepts for distributed man- 
agement with access control, automated analysis and netwoik 
management Amotions, fiherhig and storage of variable data, 
and a gonerio notwoxk mnnagcmcnt tnfonnation exchange lan- 
guage. 

Conclusion 

NETMATE addresses the management needs of network 
administrators by supporting a generic datz, model and a com- 
prehensive set of distributed tools. The modd exploits generic 
properties and relationships exhibited by network components 
In most networks in order to fiicUitate cffictent analysis metb* 
ods. The modd is both comprehensive and extensible. Many 
complex issues rdated to dtstributedmanattment are integrat- 
ed into the design and research of the model ardiitectnre. The 
sdfHsontained to61s(e^, UI, OCP. analy^ modules, and trou- 
ble ticketing) encai»ulate specific fimctions and lend tbaor 
selves to a modular and efiEideni network management solu- 
tion. 
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